千呼萬喚，2026 年 6 月 1 日兒童節當天，MiniMax 第三代旗艦模型 M3 終於發佈了。

光看官方解讀，六個關鍵詞就可以概括這款模型的全部亮點：Coding 能力、1M 上下文、原生多模態、Computer Use、低價 Token Plan、開源。

能力上，作為國內首個集齊了 Frontier 三件套——前沿 Coding/Agentic 能力、百萬 token 級超長上下文、原生多模態的開源模型的國產模型，M3 的實力不必多提。

畢竟在此之前，能同時集齊這三項的，只有 Claude Opus 4.7、Gemini 3.1 Pro 和 GPT-5.5 這些海外頭部閉源模型。

能力固然耀眼，但這次主要想聊一聊的，是它的價格。

官方資訊顯示，這次的 MiniMax Token Plan 設計上，個人開發者套餐分三檔：Plus 49 元/月，6 億 token；Max 119 元/月，18 億 token；Ultra 469 元/月，55 億 token。

換算下來，Max 檔在相近價格下約等於 Claude 訂閱的 15 倍用量。

過去在 Chatbot 時代，很多人可能對這種性價比沒什麼概念。畢竟使用者問一句，模型答一句，成本還比較溫和。到了 Agent 時代，模型開始學會讀倉庫、掃檔案、跑測試、看日誌、修 bug、跑測試。一次任務背後，可能是幾十次、幾百次模型呼叫。

於是，模型變聰明了，但成本也沒多少人扛得住了。

而一個聰明又有足夠性價比的模型，對很多個體以及企業而言，有時候往往就是 AI 真正走向落地的臨門一腳。

過去大家討論 AI 替代人、解放人，常常默認 AI 一定更便宜。

但這句話成立，是有限制條件的。

特別是 Coding Agent 場景，前段時間，一篇關於 Agentic Coding 成本的研究，分析了 8 個前沿模型在 SWE-bench Verified 上的運行軌跡發現一個有意思的現象：

Agentic Coding 類任務，token 消耗不是線性增長，甚至可以達到普通程式碼問答的 1000 倍。更麻煩的是，有時候，token 燒得更多，精準率並不一定繼續變高，很多任務的精準率會在中等成本區間達到峰值，然後趨於飽和。

背後邏輯在於，Coding 需要使用者把完整的項目檔案、程式碼上下文喂給 AI，才能產出真正可用的程式碼。是典型的輸入 token 遠大於輸出 token 的場景。越是生產級場景，上下文成本就越是貴得離譜，有時候，甚至會超過人力成本本身。

這也就解釋了為什麼很多過去在 AI 使用上非常激進的企業，從今年開始，出現了態度反覆橫跳：

一個極端案例是 OpenClaw。其創始人 Peter Steinberger 曾曬出 30 天消耗約 130 萬美元 OpenAI API token 的帳單，覆蓋 6030 億 token、760 萬次請求，背後是約 100 個 Codex agent 在跑自動化開發任務。

Uber 更是 CTO 與 COO 先後公開下場吐槽，公司到 2026 年 4 月已經花完了全年 Claude Code 預算。

在這一背景下，MiniMax M3 的性價比已經不是便宜一點的問題，更是 Agent 真正普及前的臨門一腳：

Agent 不能試錯就做不了複雜任務；但試錯太貴，企業就會關止步不前，個人開發者也會變得保守。

以前模型競爭的核心的是智力上限，agent 時代，單位成本下的有效工作量才是真正的重點。

這就是為什麼我認為 M3 的性價比其實也是產品能力的一部分。

但支撐這個性價比的根源在於那裡？性價比背後，產品的體驗又究竟如何？

需要更強的 Coding 和長程自主迭代

價格解決的是敢不敢用，下一步使用者關心的，是值不值得用。

M3 官方給出的 Coding benchmark 很好看：SWE-Bench Pro 59.0%、Terminal Bench 2.1 66.0%、SWE-fficiency 34.8%、KernelBench Hard 28.8%、MCP Atlas 74.2%。

這些數字當然重要，但我更建議把它們當成一個參考系，而不是結論。真正的亮點其實是官方用 M3 實現的兩個實際案例：復現論文和最佳化 CUDA 的 Hopper FP8 GEMM kernel。

先看看 Hopper FP8 GEMM kernel 最佳化案例。

在這個任務裡，M3 的起點只有任務描述、benchmark 指令碼和一個不能直接運行的 Triton 骨架，沒有 reference 高性能實現。

M3 在約 24 小時內完成 147 次 benchmark 提交和 1959 次工具呼叫，把 Hopper FP8 GEMM 的硬體峰值利用率從 7.6% 推到 71.3%，實現 9.4 倍加速。

這裡最重要的細節其實不是最後的 71.3%，而是最優解出現在第 145 次提交。作為對比，除 Opus 4.7 和 M3 外，其餘模型大多在前 30 次提交內不再取得新進展並主動退出。

也就是說，模型並不是前幾輪靈光一閃就完成任務，而是在多個平台期裡繼續診斷、嘗試、驗證、推翻，再嘗試。

這個過程裡，模型需要需要維持目標、記住歷史、理解 benchmark 反饋，還要避免在多輪改動中把系統搞亂。

這也是 Coding Agent 和程式碼補全工具的分界線。一個普通 vibe coding 群體可能沒意識到的現實在於，真實的生產級環境中，無論 AI 還是人類，產出程式碼第一次跑不起來很正常；跑起來之後性能差也很正常；最佳化完引入新 bug 也很正常。而工程任務的大部分時間，都花在診斷、驗證、回滾、再嘗試。

這個能力的背後，不能只靠模型參數更大，還需要訓練資料更接近真實使用者邏輯。為此，MiniMax 建構了互動式使用者模擬器，模擬真實開發者在同一個 session 中不斷補充需求、調整方案、派發任務、反饋修正。

這也是為什麼我在前面說，benchmark 結果漂亮固然很重要，但不能直接將其平移到生產環境。今天很多 coding benchmark 仍然是 single-turn task，但真實協作一定是 multi-turn、multi-file、multi-tool、multi-objective。誰能把訓練和評測從一次性解題推進到持續協作，誰才更接近下一代 Coding Agent。

另外再看一下復現論文案例，這個也同樣很有意思。M3 被要求復現 ICLR 2025 Outstanding Paper Award 論文 Learning Dynamics of LLM Finetuning。它自主運行了接近 12 小時，產出 18 次 commit 和 23 張實驗圖表，跑通核心實驗，並觀測到 SFT 階段預測機率變化、DPO 的 squeezing 效應，以及 Extend 緩解方法。

這個任務的特點在於任務本身夠複雜，需要的能力也夠多。模型要讀論文正文，理解公式和圖表，寫實驗程式碼，跑訓練指令碼，檢查結果是否對齊論文結論，再根據偏差調整實驗設定。這就需要，模型的智能上限、長上下文、程式設計、多模態、工具呼叫、事實糾偏各種能力必須同時成立。

而 M3 的一大特點，正在於它是從 Step 0 開始做多模態混合訓練，而且使用的是文字、圖像和其他模態自然交錯的資料。

放到 Agent 語境裡，它意味著模型更容易進入真實工作現場，幫開發者看架構圖、錯誤截圖、性能曲線、PR 頁面和終端輸出，幫研究員讀論文正文，以及表格、圖像、曲線和公式。還能幫企業員工在 ERP、Excel、網頁後台、本地客戶端、聊天工具之間來回切換，讓多模態與智能本身，成為牢不可分的一體兩面。

我在測試裡直接讓 AI 根據《西遊記》小說，制定一個互動地圖。

完成這個任務的難點在於，首先模型要自己找到《西遊記》原文共 100 回，60 余萬字並通讀理解。

在此基礎上，做西遊互動地圖最難的是原著地名散亂、虛實空間混雜：行程描述唯寫里程但沒有坐標，所有的動線、事件跨百回分佈，必須全本上下文統籌梳理空間關聯；而仙界洞府等多層平行空間中的各種虛構場景沒有現實 GIS 參照，同時一些凡間位置，雖然有現實世界原型，但又並未在書中明說。

要把這些文字描述轉成地圖畫面、自動生成開發程式碼，對模型的上下文能力、工具呼叫能力、多模態能力、agent 協作能力，甚至審美都是不小的考驗。

這是最終的生成 HTML 頁面的截圖（部分展示），可以看到，不僅路線圖與劇情完全吻合，甚至不同地點可能對應的現實世界方位，也基本一致。

比如五行山對應現實世界河北五指山，法門寺在陝西西安，通天河在青海玉樹附近，而流沙河對應現實世界新疆塔里木的開都河，與現實世界原型的參考方位幾乎一一對應。

稀疏注意力搞定 1M 上下文已經不新鮮，

講完價格和 Coding，到這裡，很多人應該也就能理解 M3 設計的稀疏注意力機制支撐起的 1M 上下文背後的邏輯了。

長上下文現在已經不稀奇。很多模型都在宣傳 200K、1M，甚至更長。問題在於，窗口長不代表模型會用。

Agent 不可能每一步都從零開始思考，它必須把過去的失敗、使用者偏好、項目結構、工具反饋沉澱進上下文。相應的，模型的上下文中會堆滿了超長的程式碼檔案、終端日誌、失敗記錄、benchmark 輸出、使用者反饋、歷史工具呼叫和中間推理痕跡。

長上下文是實現這一切的基礎。但有時候，窗口越長，也就意味著各種中間狀態、無關內容構成的噪音越多，輸出質量越差，成本也越容易爆炸。

在這一背景下，使用稠密注意力，上下文長度的擴張以及輸出效率會受到限制，成本也會隨之失控。

使用普通稀疏注意力，能省成本，但容易犧牲細粒度資訊定位能力。

但偏偏，Agent 執行過程中，最怕漏細節。一次工具呼叫裡的關鍵報錯、某個程式碼檔案裡的邊界條件、某張圖裡的曲線異常，都可能決定任務能不能繼續。

因此，實現長上下文字身不難，真正難的是如何實現成本、效率、命中率的三者得兼。

瞭解行業背景的都知道，MiniMax 不是今天才開始做長上下文和稀疏注意力。

2025 年年初的 MiniMax-01 就用了 Lightning Attention，並且把模型訓練上下文做到 1M，推理上還嘗試外推到 4M 的更長上下文；

後來去年同一時期的 MiniMax-M1 繼續使用 hybrid attention，加上 MoE 和強化學習，主打長上下文、長推理和複雜軟體工程任務。

到了後來的 M2，MiniMax 還一度短暫回退到稠密注意力路線，直至此次 M3，MiniMax 借助 MSA 再次回歸稀疏注意力。

相比業內的其他稀疏注意力方案 DSA、MoBA 等，MSA 通過 scalable sparse attention、document-wise RoPE、KV cache compression 和 Memory Parallel 等設計，可以把訓練和推理複雜度做成線性，並在從 16K 擴展到 100M tokens 時保持低於 9% 的性能退化。並通過精準 KV 分塊升級，在算子層通過 KV outer gather Q 減少重複讀取，整體的計算訪存比是開放原始碼的 Flash-Sparse-Attention 和 FlashMoBA 的 4 倍以上。

而借助MSA，M3 能做到 1M 上下文下每 token 計算量只有上代模型 1/20、prefill 超過 9 倍加速、decoding 超過 15 倍加速。多數場景下，能力直接追平全注意力模式。

這類最佳化聽起來很底層，但使用者端會感受到兩件事：長任務跑得便宜，並且資訊的把握非常精準。比如這裡，我

把一整本《國富論》喂給 M3，做了一個亞當斯密邏輯下的模擬世界遊戲。

這其中的難點在於，《國富論》通篇都是定性社科論述，分工、財稅、外貿、資本、薪資的經濟傳導邏輯零散分佈全卷，只有百萬級上下文才能完整通讀全書，提煉環環相扣的量化演算規則，把斯密的文字理論轉化成稅率、生產率、財富聯動的數值公式。

在此基礎上，要完成模擬世界遊戲的建構，還需要靠 Agent 不斷完成長時序推演，理解玩家減稅、修路等政令可能導致的結果，最後還能分短中長期按古典經濟學邏輯迭代面板資料，全程不能違背原著底層經濟規律。

最後結果上，可以看到 M3 精準還原了斯密理論在實際生活中環環相扣，稅制、關稅會直接左右生產率與財富增減，辦學政策會在中期、長期對稅務、對勞動生產率、對國家財富積累以及人口產生不同的影響。使用者自訂政策後，系統會自動逐年演算經濟變遷，完整還原國富論裡政策隨時間釋放經濟紅利的設計。

而長上下文也只有做到這一步，才有意義。

Agent 時代，最稀缺的不是智能，

M3 的發佈背後，各種單點最佳化固然重要，但它同時也是國產模型開始從追 benchmark 轉向做系統、讓 agent 真正能落到所有企業與個人日常所需中的一個重要嘗試。

複雜任務需要長上下文。長上下文會帶來成本、速度和資訊命中率問題，所以需要 MSA 這種更高效的注意力機制。

Coding Agent 需要持續迭代。持續迭代會消耗大量 token，所以模型既要會寫程式碼，也要能在多輪失敗裡維持目標、讀懂反饋、繼續推進。

真實工作環境是多模態的。只會處理文字，Agent 就很難處理截圖、圖表、後台、Excel、PR 頁面和終端輸出混在一起的任務。

高頻使用還要足夠便宜。否則使用者不會讓 Agent 充分試錯，企業也不敢把它接入真實流程。

每個點單獨看都不是第一次出現，但組合起來構成的，是 Agent 能力進入開發者和企業日常工作流的敲門磚。 (極客公園)

彙整鉅亨號中所有使用「Plus Token Plan」關鍵字，所發布的內容 (依照時間排序，最新在前，舊的在後)`